Fragment Specifiers for Generic Arguments #3442

JarredAllen · 2023-06-01T20:44:34Z

I wrote up my thoughts from this rust-internals thread into an RFC.

programmerjake · 2023-06-01T21:08:44Z

text/0000-fragment-specifiers-for-generic-arguments.md

+things instead.
+
+Also, should `:generic_bound` include the preceding `:` in the match (e.g. `: 'a
+ SomeTrait` in the example above)? And likewise with the `=` before


don't word-wrap in the middle of a ` code span, it doesn't get rendered properly

Oops, I guess I need a better editor config. Fixed in d77ac90

oxalica

This RFC does not include specifiers for where-clause, which is highly related to generics. Is this intentional? Maybe we should mention this in text.

oxalica · 2023-06-02T06:15:21Z

text/0000-fragment-specifiers-for-generic-arguments.md

+
+* `:generic`: A full set of generic parameters and their bounds (e.g. `<'a, T:
+  'a + SomeTrait, const N: usize>`)
+* `:generic_param`: A generic parameter (e.g. `'a`, `T`, or `const N`)


const N does not work for the macro example above, $param:generic_param $( : $bound:generic_bound )?. Const generics have the syntax const $param:ident : $ty:ty $(= $default:expr)?. Note that it is a type instead of generic bounds after the colon, so syntactically it should also accept non-trait-like types like const N: (i32, i32), though it's forbidden currently.

This was a deliberate deviation from the default syntax to make it easier to parse an arbitrary set of generic parameters. If we use the fragment specifiers as I defined them in the example macro defined in the RFC (< $( $param:generic_param $( : $bound:generic_bound )? ),+ > , then this successfully matches <const N: usize> ($param being const N and $bound being usize.

If it matches as you're requesting that it match, then the same pattern will match this trait, but it will also allow in nonsense like <const N: usize: 'a + SomeTrait> which my approach avoids. I'm not sure how one could change the pattern to avoid allowing for nonsense like that.

Though also, my approach would match <const N>, which is also nonsense, so idk which one would be better to reject while matching the macro. I'm open to changing it if you have arguments for your way of splitting the definition between the two fragment specifiers being better.

To your last point, the definition that I give for :generic_bounds does explicitly allow for a type, so that syntax would be accepted.

Your approach also matches const N: 'a and 'a: usize (see my comment below)

oxalica · 2023-06-02T06:24:18Z

text/0000-fragment-specifiers-for-generic-arguments.md

+* `:generic_bound` matches the
+  [`TypeParamBounds`](https://doc.rust-lang.org/reference/trait-bounds.html)
+  (can be the bounds on a type parameter) or
+  [`LifetimeBounds`](https://doc.rust-lang.org/reference/trait-bounds.html) (can
+  be the bounds on a lifetime parameter) grammar items, or a type (can be the
+  bounds on a const parameter).


Should it be named "generic_bound" or "generic_bounds"?
Also that TypeParamBounds does not allow empty, while the generic syntax do allow <T: /*nothing*/> (except for const generics). If we want it to match multiple bounds, it should also match no bounds.

Neat, I never knew that Rust allowed <T:> as a generic parameter list. That doesn't seem very useful to me, but I'll change it to allow that since I agree that it should be matched if Rust allows it.

clarfonthey · 2023-06-03T00:15:58Z

This RFC does not include specifiers for where-clause, which is highly related to generics. Is this intentional? Maybe we should mention this in text.

I think this would be nice longer-term, but at least for now, the extremely simple case of being able to check for pieces like <T, const N> without resorting to using token-trees is pretty good on its own. That said, the inclusion of bounds in this RFC does beg the inclusion of where bounds too.

Aloso · 2023-06-04T14:37:42Z

I like the general idea of this RFC, but I don't like that a macro accepting $( $p:generic_param $( : $b:generic_bound )? ),* can accept illegal syntax (like a lifetime followed by a trait bound, or a const generic followed by a lifetime bound).

I also don't like that matching all generics syntax with the more granular fragments is pretty verbose:

< $(
    $( #[$m:meta] )*
    $p:generic_param
    $( : $( $b:generic_bound )? )?
    $( = $d:generic_default )?
),* $(,)? >

a where clause could be written like this, if we require trailing commas:

where $(
    $( $l:lifetime $( : $( $b1:generic_bound )? )? , )?
    $( $( for $f:generic )? $t:ty $( : $( $b2:generic_bound )? )? , )?
)*

But this isn't forward compatible with

return type notation (where Self::method(): OtherTrait)
equality constraints (where Self::ID = {N + 1})
possibly more

Aloso · 2023-06-04T14:55:10Z

Maybe it would be best to remove :generic_param, :generic_bound and :generic_default from the RFC (unless you can give an example where they're useful), and instead add :where_clause.

JarredAllen · 2023-06-06T00:07:27Z

I added a :where_clause, as per multiple requests. They were excluded initially because I forgot that they existed, not for any real reason.

JarredAllen · 2023-06-06T00:15:20Z

I like the general idea of this RFC, but I don't like that a macro accepting $( $p:generic_param $( : $b:generic_bound )? ),* can accept illegal syntax (like a lifetime followed by a trait bound, or a const generic followed by a lifetime bound).

I also don't like that matching all generics syntax with the more granular fragments is pretty verbose:

Yeah, sadly the only way to prevent it from accepting illegal syntaxes like const N: 'a or 'a: usize would make it even more verbose and complicated to match the entire generics syntax, which makes your other point worse. Though, you don't need the $()? around :generic_bound anymore, I didn't know that nothing could be put there and have since updated it to allow that, so it's slightly less verbose.

I tried to strike a happy medium where relatively few illegal syntaxes are allowed (I think they've all been said on this page? Unless I'm missing some) but also it's reasonably non-verbose to parse the full generic parameter definition syntax and we're not adding too many new fragment specifiers into the language, and the split is done in such a way that it could be useful for implementing macros.

I'm open to any suggestions you have for making that trade-off better, but this was the best balance between the two goals I could think of.

CohenArthur · 2024-01-05T15:40:29Z

text/0000-fragment-specifiers-for-generic-arguments.md

+When explaining fragment specifiers, this can be explained by adding the new
+fragment specifiers and their descriptions:
+
+* `:generic`: A full set of generic parameters and their bounds (e.g. `<'a, T:


maybe a nit but generic being singular confuses me. I think it would make more sense for it to be named generics or generic_set, or anything to add plurality to the concept, especially since it would be responsible for parsing the opening and closing angle brackets

Fragment Specifiers for Generic Arguments

1927252

programmerjake reviewed Jun 1, 2023

View reviewed changes

Reflow to fix inline code span

d77ac90

ehuss added the T-lang Relevant to the language team, which will review and decide on the RFC. label Jun 1, 2023

oxalica suggested changes Jun 2, 2023

View reviewed changes

JarredAllen added 2 commits June 5, 2023 16:18

Generic bounds may be empty

d666f15

Add a fragment specifier for where-clauses

8db5d8d

CohenArthur reviewed Jan 5, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fragment Specifiers for Generic Arguments #3442

Fragment Specifiers for Generic Arguments #3442

JarredAllen commented Jun 1, 2023 •

edited by rustbot

Loading

programmerjake Jun 1, 2023

JarredAllen Jun 1, 2023

oxalica left a comment

oxalica Jun 2, 2023 •

edited

Loading

JarredAllen Jun 5, 2023

Aloso Jun 5, 2023 •

edited

Loading

oxalica Jun 2, 2023

JarredAllen Jun 5, 2023

clarfonthey commented Jun 3, 2023

Aloso commented Jun 4, 2023 •

edited

Loading

Aloso commented Jun 4, 2023 •

edited

Loading

JarredAllen commented Jun 6, 2023

JarredAllen commented Jun 6, 2023

CohenArthur Jan 5, 2024

Fragment Specifiers for Generic Arguments #3442

Are you sure you want to change the base?

Fragment Specifiers for Generic Arguments #3442

Conversation

JarredAllen commented Jun 1, 2023 • edited by rustbot Loading

programmerjake Jun 1, 2023

Choose a reason for hiding this comment

JarredAllen Jun 1, 2023

Choose a reason for hiding this comment

oxalica left a comment

Choose a reason for hiding this comment

oxalica Jun 2, 2023 • edited Loading

Choose a reason for hiding this comment

JarredAllen Jun 5, 2023

Choose a reason for hiding this comment

Aloso Jun 5, 2023 • edited Loading

Choose a reason for hiding this comment

oxalica Jun 2, 2023

Choose a reason for hiding this comment

JarredAllen Jun 5, 2023

Choose a reason for hiding this comment

clarfonthey commented Jun 3, 2023

Aloso commented Jun 4, 2023 • edited Loading

Aloso commented Jun 4, 2023 • edited Loading

JarredAllen commented Jun 6, 2023

JarredAllen commented Jun 6, 2023

CohenArthur Jan 5, 2024

Choose a reason for hiding this comment

JarredAllen commented Jun 1, 2023 •

edited by rustbot

Loading

oxalica Jun 2, 2023 •

edited

Loading

Aloso Jun 5, 2023 •

edited

Loading

Aloso commented Jun 4, 2023 •

edited

Loading

Aloso commented Jun 4, 2023 •

edited

Loading